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Safety critical avionics software is a natural application area for formal verification. This is reflected 
in the formal method’s inclusion into the certification guideline DO-178C and its formal methods 
supplement DO-333. Airbus and Dassault-Aviation, for example, have conducted studies in using 
formal verification. A large German national research project, Verisoft XT, also examined the appli¬ 
cation of formal methods in the avionics domain. 

However, formal methods are not yet mainstream, and it is questionable if formal verification, 
especially formal deduction, can be integrated into the software development processes of a resource 
constrained small or medium enterprise (SME). ESG, a Munich based medium sized company, has 
conducted a small experimental study on the application of formal verification on a small portion of a 
real avionics project. The low level specification of a software function was formalized with ACSL, 
and the corresponding source code was partially verified using Frama-C and the WP plugin, with 
Alt-Ergo as automated proven 

We established a couple of criteria which a method should meet to be fit for purpose for industrial 
use in SME, and evaluated these criteria with the experience gathered by using ACSL with Frama-C 
on a real world example. The paper reports on the results of this study but also highlights some issues 
regarding the method in general which, in our view, will typically arise when using the method in the 
domain of embedded real-time programming. 


1 Introduction 

Recent advances in automated theorem provers have brought formal methods from purely academic ex¬ 
ercises close to industrial use. Airborne software has early been recognized as a suitable candidate for 
the application of formal methods ifldll^ . Airbus, for example, has examined the formal method Caveat 
to replace unit tests ifTSl . Since Airbus is a trend setter in the avionics industry at least in Europe, one 
can expect the obligation to use formal methods for the development of highly safety critical airborne 
software in future. Moreover, standard organizations start to incorporate formal methods into their reg¬ 
ulations as one can already see with the formal methods supplement DO-333 llT2]l of the new version of 
the avionics software certification guidelines, DO-178C ifTTI . Another well-known example is the Com¬ 
mon Criteria for Information Technology Security Evaluation that demand the use of formal methods for 
the highest Evaluation Assurance Eevels EAE 6 and EAL 7 f9l|. It is probably safe to assume that more 
and more development standards will mandate the application of formal methods in the future. This 
will force also small and medium enterprises (SME) that develop safety critical software to consider the 
adoption of formal methods in the long run. 

ESG as a medium sized company that develops airborne system solutions has therefore launched a 
small experimental study to examine if formal verification can be integrated into its development pro- 
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cesses for airborne software, and to identify the prerequisites for an adoption of formal methods in future 
DO-178C compliant software projects. 

In Germany, the Verisoft XT project [61 examined the application of formal methods in an industrial 
context. ESG participated in a work package of that project that examined the application of formal 
methods in the avionics domain Q. This experimental study is a continuation of ESG’s work in that 
project. 

ACSE is an acronym for “ANSI C Specification Eanguage” provided for the open source tool plat¬ 
form Erama-C EITOl. It is a behavioral specification language that can express properties of C source 
code including pre-conditions and post-conditions of C functions using first order logic. The ACSE 
specifications are provided as annotations to the source code. The WP plug-in of the framework allows 
a deductive verification of the source code against the formal annotations in ACSE @. 

DO-178C defines Low-Level Requirements (LLR) as software requirements from which source code 
can be directly implemented without further information. In the software projects we have been involved 
in, these requirements were natural language annotations to the subroutines or function declarations 
provided by the interfaces of the software modules. It is therefore natural to consider ACSE as a candidate 
to formally express the low-level requirements. 

Several so-called DO-178C objectives are associated with low-level requirements that must be ful¬ 
filled for accepfance of the software by certification authorities. One such objective is the verifiability of 
low-level requirements. This objective is indeed achieved when a formal notation is used. Another ob¬ 
jective is the compliance of the source code with the low-level requirements, which is usually shown by 
code review. These time consuming reviews may be replaced by automated formal verification. Blasum 
et al fll discuss these and other DO-178C objectives for the formal methods of the Verisoft XT project. 

The major goal of the study was to check if formal notations can be used in a real project to formally 
express real world low level requirements, i.e. to see if a certain formal method is fit for use in industrial 
practice in general and for ESG in particular. A secondary goal was to examine if available tools can 
verify such annotated code and even be able to find bugs not yet discovered by testing, which would 
prove one of the claimed advantages of formal methods over testing. 

The first step was to establish criteria which a formal notation and its supporting tools should meet 
in order to be ready for industrial use in an SME setting. In a second step, we selected a function from 
a real avionics project and formalized the natural language specihcations of the associated C functions 
into ACSE specihcations. It was in this step that we encountered the hrst obstacles although the selected 
function was rather trivial. 

These obstacles are, in our view, quite typical for embedded real-time programming. The problems 
were solved with support of Erama-C experts via the Erama-C mailing list. However, the solutions are 
not fully satisfactory which may be inherent to the approach, as it will be discussed later. 

In a next step, we attempted to verify the source code against the ACSE specihcation while instru¬ 
menting the source code with assertions in order to guide the proven Not ah verihcation attempts were 
successful. We were only able to explain some of the failed attempts before running out of time[^ In a 
hnal step, we compared our experience in using tool and method against the formerly established criteria. 

'ironically, the failed proof attempts that we were not able to explain were those where the prover timed out. 
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2 Industrial Fit for Purpose 

The main goal of the study was to check if formal specification and verification is already suitable to be 
used in an industrial rather than academic context, in a small to medium sized enterprise. In order to 
decide on this question, a number of criteria must be fulfilled: 

• Nofafion and mefhod should be wifhin fhe normal range of experience of an average soffware 
engineer, i.e. if should be usable for engineers wifhouf a PhD in formal logic. 

• The complexify of fhe formal language should have fhe same level as a programming language 
such as Ada or C. The learning curve should be moderate. 

• Training courses should be available. 

• Information sources such as fexf books, guidelines, efc. should be available. 

• The fools used for specificafion and verificafion should be mafure and sfable. 

• The fool should provide feedback fo fhe user in case a proof fails, ideally by showing fhe places 
where fhe proof fails fogefher wifh a counfer example. 

For avionics projecfs fhaf are going fo be developed in accordance wifh DO-178C, addifional criteria 
derived from DO-333 objectives such as mefhod soundness, coverage criferia or fool qualification have 
fo be considered. Such considerafions were nof in fhe scope of fhis sfudy. For a discussion of fhese 
criferia for VCC |[20l . a fool similar fo Frama-C, see f7l|. 

3 Frama-C, WP Plugin and Alt-Ergo 

Avionics soffware is usually real-fime, embedded, i.e. hardware relafed, resource consfrained soffware 
fhaf often implemenfs complex arifhmefic algorifhms. One will find fype casfs, especially befween infe- 
ger and hardware addresses, and low level poinfer handling, as well as floaling poinf calculafions. 

Embedded projecfs often do nof use an operafing sysfem so fhaf fhe developer musf direcfly access 
and manipulate fhe hardware. 

The sfricf real-fime requiremenfs sometimes lead fo fhe applicafion of fhe mosf efficienf programming 
consfrucfs fhaf may be difficulf fo verify wifh formal mefhods. 

A formal nofafion and ifs supporfing fools musf address fhese consfrainfs. This is fhe case wifh fhe 
open source fool plafform Frama-C fogefher wifh ifs WP plugin. Frama-C is organized info a plug-in 
archifecfure wifh a common kernel fhaf allows fhe plug-ins fo inferacf wifh each ofher using ACSL as 
lingua franca. 

The WP plugin was selected because if well supporfs fhe aforemenfioned properties of avionics 
soffware. WP uses memory and arifhmefic models in order fo model memory managemenf of dynamic 
sfrucfures (pointers) and properties of integer and real variables E|. 

4 Function Selection 

The examples in fhis sfudy have been faken from fhe confrol soffware of a sensor fhaf ESG has developed 
as a cenfral componenf of a pilof assisfance sysfem for a milifary helicopfer. The sensor confrol soffware 
has been developed in accordance wifh DO-178B, level D and was accepfed by fhe German milifary 
certification aufhorify WTD 61/ML in 2014. 
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Micro Controller 


Figure 1: Temperature Monitoring Hardware 
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Figure 2: Temperature Monitoring Call Hierarchy 




Monitoring the environmental conditions, especially the temperature, is important to the correct op¬ 
eration of the sensor. Therefore, two temperature sensors (NTCl and NTC2 in figure [T]l are installed 
within the equipment for redundant temperature measurements. 

The temperature monitoring function is part of the sensor’s control program that is running on 
the processor shown in figure [T] If calculafes fhe mean femperafure of bofh readings, as long as 
fhey do nol differ more fhan a cerfain amounf (declared as posifive integer TEMP_FAIL). If accepfs 
MAX_TEMP_ERR_CNT consecufive differences larger fhan TEMP .FAIL before refuming fhe error EC.TEMP. 

Figurej^shows fhe femperafure monitoring call hierarchy: fhe funcfion cbit_check_temperature 
is execufed every 500ms. This funcfion calls acqjneasure.temp fhaf refurns fhe femperafure readings 
of fhe fwo femperafure sensors. To do so, fhe laffer funcfion calls adc_read to obfain fhe volfage levels 
from fhe Analog-Digifal converfers (ADCs, see Fig. [T]) connecfed fo fhe femperafure sensors. 

If fhe femperafure reading is oufside operational limifs, fhis facl is reported as a working condition in 
a module slate variable fhaf is sef by fhe function cbit_set_working_cond. 

This sef of funcfions has been selecled for fhe following reasons: 

• The funcfions are ralher simple bul already required some of fhe major concepls of ACSL for Iheir 
formalizafion. 

• The selecled funcfions have been laken from a real projecl, if is real code and real specificalions 
wifh all fhe flaws fhaf fypically occur in a lime conslrained induslrial projecl. 

• The funcfions cover a slandard problem (moniforing a cerfain value oblained from an analogue-lo- 
digilal (AD) converter) so if does nof reveal inlelleclual properly. They are well suited for public 
discussion. 

• The example could well be isolaled: fhe source files confain only fhe selected C funcfions wilhouf 
failing compilafion and analysis. 

• The whole sef of funcfions encompasses purely algorilhmic as well as hardware relaled functions. 
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5 Formalization and Verification of LLR 

The analysis approach is the same for all functions: at first, the original specification of the C function is 
formalized using ACSL behavior specifications. In a subsequent step, verification of the source code is 
attempted to show by proof that the implementation follows the specification. This is actually an iterative 
approach which often needs adding instrumentation (assertions, loop invariants) to the source code. 

To illustrate the approach, we use the most simple function cbit_set_work_cond that simply writes 
to a module variable, i.e. a persistent variable only known within the module chit. This variable is used 
in other parts of the program but is read and write protected by setter and getter functions. 

The update of the state variable is guarded - the function takes a new value of the working condition 
as a parameter new_cond and writes that to the module variable WorkCondition unless this module 
variable has been set previously. The only exception is the special parameter value NCD_N0_C0MMAND 
that can overwrite all settings. A natural language formulation of the low level requirements would read 
as follows: 

1. If the value of the input parameter new_cond is equal to NCD_ND_CDMMAND, then the module vari¬ 
able WorkCondition is set to this value NCD_ND_COMMAND. 

2. If the current content of the module variable WorkCondition is equal to NCD_IDLE_EMIT, the 
module variable WorkCondition is set to the value of the input parameter new_cond. 

3. If the value of the module variable WorkCondition is not equal to NCD_IDLE_EMIT and the 
value of the input parameter new.cond is not equal to NCD_ND_COMMAND, then the current value 
of WorkCondition is not changed. 

The attempt to formalize these LLR into ACSL encounters the first obstacle: the internal module 
variable - a static variable of file scope - is nol visible in fhe header file where fhe formalized specificalion 
is located. The solufion was fo infroduce a ghosf variable fhaf represenfs fhe infernal dafa, which in effecl 
is uncovering fhe infernal variable, i.e. fuming parfs of fhe module inside ouf. The ghosf variable for fhe 
infernal sfafe is locafed in fhe header file: 

//@ ghost uintl6_t gWorkCond = NCD_IDLE_EMIT; 

The behavioral specificalion, i.e. fhe Iranslalion of fhe LLR above, is now slraighl forward: 

/*(§ 


@ 

behavior 

NoCommand: 


@ 

assumes 

new_cond == 

NCD_N0_C0MMAND ; 

@ 

ensures 

gWorkCond == 

new_cond; 

(§ 

behavior 

ModifyWC: 


(§ 

assumes 

gWorkCond == 

NCD_IDLE_EMIT ; 

(§ 

assumes 

new_cond != 

NCD_N0_C0MMAND; 

(§ 

ensures 

gWorkCond == 

new_cond; 

(§ 

behavior 

KeepWC: 


(§ 

assumes 

((gWorkCond 

!= NCD_IDLE_EMIT) && 

@ 


(new_cond ! 

= NCD_N0_C0MMAND)) ; 

(S 

ensures 

gWorkCond == 

Void(gWorkCond) ; 

@ 

complete 

behaviors ; 


(§ 

disj oint 

behaviors ; 


@*/ 




void cbit_set_work_cond( uintl6_t new_cond); 
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The three behavior specifications above directly correspond to the natural language requirements 
so that they could be replaced by the formalized requirements. The behavior clause can be named 
as shown in the example which facilitates traceability to higher level requirements, an objective that is 
strongly emphasized in aviation standards. The assumes clauses represent the conditional part of the 
natural language requirements and are evaluated at the beginning of the execution of the function. More¬ 
over, with complete and disjoint clauses one can automatically verify completeness and consistency 
of the formal specification. 

Note that assigns clauses have been omitted from the specification above although this is discour¬ 
aged by the ACSL reference manual (|41, section 2.3.5). However, adding assigns clauses generates 
verification conditions that cannot be proved. This is due to the fact that the function modifies a sfafe 
variable of file scope (WorkCondition) which cannof be listed in fhe assigns clause because if is nol 
visible fhere. Several solufions for fhis problem are under discussion on fhe fool’s mailing lisf af fhis lime 
of wrifing. 

For fhe verificalion, fhe ghosl slate variable musl be aligned wifh fhe infernal module variable using 
asserlions, as shown below: 

void cbit_set_work_cond ( uintl6_t new.cond) 

{ 

//@ assert gWorkCond == WorkCondition; 

if ((WorkCondition == NCD JDLE_EMIT) || (new_cond == NCDJSOTDMMAND)) 

{ 

WorkCondition = new.cond; 

//@ ghost gWorkCond = WorkCondition; 

} 

} 

The assertion in line 3 is necessary to inform the prover that the internal state is always equal to the 
ghost state. It is not possible to prove it. 

The WP plugin generates a verification condition for every assertion. The verification conditions 
are similar to test cases in traditional verification so that a verification condition that cannot be proved 
is identical to a test case that has failed. Therefore, justification is needed for the assertion in line 3 to 
fulfill objecfive FM2 of fable FM.C-7 of DO-333 fhal demands fhal formal analysis resulls are correcf 
and discrepancies are explained. 

Represenfing internal sfafe wifh a ghosl variable is nol oplimal as indicaled above. The function 
cbit_set_work_cond and ils counlerparl cbit_get_work_cond would have been belter specified by 
using algebraic specificalion techniques in fhe way if is shown in |[8l for fhe slack example. The approach 
described fhere Iransforms fhe axioms info additional, ACSL annofaled C code. This essenfially means 
thaf C code is used as low level requiremenls which is nof accepfabl^ The inclusion of algebraic 
specification techniques info ACSL would probably be fhe mosl eleganl solulion for fhis problem. 

6 Obstacles 

The previous seclion has already discussed one of fhe obslacles we encounfered when applying a formal 
nolalion lo fhe specification of LLRs, which is fhe need fo address internal sfafe. There were additional 
issues which will be described in fhe following subsections. 


^EASA is concerned of even using pseudocode as LLR jTj 
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6.1 Specifying Behavior across multiple Invocations 

With ACSL, one can only specify a single execution of a C function. However, the result of a function 
call sometimes depends on prior executions of this or even other functions. For example, the function 
cbit_check_temperature tolerates two consecutive discrepancies in the readings of the two tempera¬ 
ture sensors before indicating an error condition. This is usually implemented with internal state variables 
(err.cnt in our example), which is a static variable in the definition of the function, not visible to the 
outside. This again cannot be addressed in the specification located in the header file. As a solution, 
a ghost variable gerrcnt has been introduced into the specification, but as in the previous section, the 
ghost variable must be updated accordingly using assertions within the body of the function. 

This solution is also not optimal because it is rather close to the implementation and discloses inter¬ 
nals of the implementation. 

A better way in this example is to specify the intended behavior with a state automaton. The Frama-C 
plugin Aorai ifTSl can be used for this purpose. It translates automaton specifications formulated in YA 
or LTL into ACSL annotations (and additional annotated C code) that can subsequently be verified with 
the WP plugin. However, one needs to learn an additional specification language to use this approach. 
We were not able to accomplish this in the time available for the study. 

During verification attempt we detected an inaccuracy in the natural language specification con¬ 
cerning the number of consecutive temperature discrepancies. The implementation is correct, but the 
specification text is misleading. 


6.2 Input Values obtained from Calls to Subroutines 

As shown in Fig. function cbit_check_temperature calls acq_temp_measure to obtain tempera¬ 
ture readings as input, and acq.temp.measure calls adc_read to get the voltage levels from the ADCs 
as input. This pattern of calling subroutines to obtain input was used a lot in the real world example. 
Again, the return values of subroutines are not visible at specification level. 

Ghost variables that represent return values of subroutines were introduced as a work-around. These 
ghost variables (T1 and T2) must be aligned with the values of the subroutine call: 

acq_measure_temp(&templ , &temp2) ; 

//@ ghost T1 = tempi; 

//@ ghost T2 = temp2; 


Although T1 and T2 act as input, their values are obtained during execution and nothing is known at 
pre-state. It is therefore not possible to express pre-conditions in the form of assumes clauses with these 
input variables. 

We introduced predicates to replace the assumes clauses, as shown in the following code snippet: 


@ predicate A_TempReadFailTrans 
@ (integer tl, integer t2, integer 
(§ (\abs(tl - t2) > TEMP_FAIL) && ( 
@ 

@ predicate A_TempReadFailPerm 
@ (integer tl, integer t2, integer 
@ (\abs(tl - t2) > TEMP_FAIL) && ( 


cnt) = 
cnt <= 2) ; 


cnt) = 
cnt > 2) ; 


These predicates are now used as replacement for the assumes clause as shown in the following 
specification of the behaviour in case of discrepancies of temperature readings: 
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(§ . . . 

0 behavior 
@ ensures 

(§ 

0 ensures 

(§ 

@ ensures 

(§ 


TempReadFailTrans: 

A_TempReadFailTrans(T1,T2,\at(gerrcnt,Pre)) ==> 
(gModuleTemp == \old(gModuleTemp)); 
A_TempReadFailTrans(T1,T2,\at(gerrcnt,Pre)) ==> 
(gerrcnt == \old(gerrcnt) + 1); 
A_TempReadFailTrans(T1,T2,\at(gerrcnt,Pre)) ==> 
(\result == EC_N0_ERR0R); 


0 behavior 
@ ensures 

(§ 

0 ensures 

(§ 

0 ensures 

(§ 


TempReadFailPerm: 

A_TempReadFailPerm(T1,T2,Xat(gerrcnt,Pre)) 
(gModuleTemp == 0); 

A_TempReadFailPerm(T1,T2,XaT(gerrcnt,Pre)) 
(gerrcnt == Xold(gerrcnt)); 
A_TempReadFailPerm(T1,T2,XaT(gerrcnt,Pre)) 
(Xresult == EC_TEMP); 








@ behavior 
0 ensures 

@ 

@ ensures 
@ ensures 
(§ ... 


TempDK: 

A_TempReadOK(Tl,T2) ==> 

(gModuleTemp == temp_average(T1,T2)); 
A_TempReadOK(Tl,T2) ==> (Xresult == EC_N0_ERR0R); 
A_TempReadOK(T1,T2) ==> (gerrcnt == 0); 


As one can see in the example above, we used a naming convention to indicate that certain predicates 
replace assumes clauses. However, this approach is not very elegant and has additional disadvantages 
that are discussed in the next subsection. 

The verification attempt revealed another weakness in the natural language specification - it is am¬ 
biguous with respect to the calculated module temperature in case of permanent temperature discrepancy. 
Here again is the implementation correct but the specification text is misleading. 


6.3 Behavior Specifications 

Without assumes clauses it is no longer possible to use complete and disjoint clauses, i.e. it is not 
possible anymore to use the tool to simply prove completeness and consistency (i.e. “disjointedness”) 
of the specification. As a work-around, one can formulate completeness and consistency properties with 
ensures clauses. Completeness is formulated as follows: 

@ ensures A_TempReadFailTrans(T1,T2,Xat(gerrcnt,Pre)) II 
0 A_TempReadFailPerm(T1,T2,Xat(gerrcnt,Pre)) II 
(§ A_TempReadOK(Tl ,T2) ; 

Consistency is expressed as 

@ ensures ! (( A_TempReadFailTrans(T1,T2,Xat(gerrcnt,Pre)) && 

@ A_TempReadFailPerm(T1,T2,Xat(gerrcnt,Pre))) II 

0 (A_TempReadFailTrans(T1,T2,Xat(gerrcnt,Pre)) && 

@ A_TempReadOK(Tl,T2)) II 

0 (A_TempReadFailPerm(T1,T2,Xat(gerrcnt,Pre)) && 

(§ A_TempReadOK(Tl ,T2))) ; 

For consistency specifications with many predicates this easily becomes complicated and nontrans¬ 
parent. 
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When taking this problem and the discussion of the previous subsection into account, it is bet¬ 
ter to avoid input values obtained from subroutine calls and to add this as a rule to the design stan¬ 
dards. In our example, the calling function of cbit_check_temperature would call adc_read, 
acqjneasure_temp, cbit_check_temperature, and cbit_set_work_cond in a row. This would also 
flatten the call hierarchy which has additional advantages as explained in the next subsection. 

There is a subtle flaw in the original natural language specification of cbit_check_temperature as 
well as in its formal counterpart. The function sets the module variable WorkCondition but this is not 
specified for all cases. It is implicitly assumed that it is not modified in these cases (which is correct), 
but formally an implementation is free to modify the working condition by any value. Such omissions 
can become critical if specifications are part of interface contracts. The method and the notation itself 
cannot prevent such specification errors. The problem is addressed by DO-333 in objective FM.5-8 of 
table FM.C-7 (Verification Coverage of Software Structure is achieved). This objective refers to section 
FM.6.7.1.3 (Completeness of the Set of Requirements) that states that for all outputs, the required input 
conditions must have been specified. The output that must be considered here is the internal module 
variable WorkCondition. 

6.4 Specification Proliferation 

The original description of cbit_check_temperature states that, if the module temperature is out¬ 
side the range between TEMP_MIN and TEMP_MAX, the module variable WorkCondition shall be set to 
NCD_TEMP_LOW or NCD_TEMP_HIGH respectively by calling cbit_set_work_cond (see sectionj^. 

This was formalized as follows: 

@ ensures (A_TempReadDK(T1,T2) && TempTooCold(T1,T2)) ==> 

(§ (gWorkCond == NCD_TEMP_LQW) ; 

This cannot be proved because cbit_set_work_cond only overwrites the working condition if the 
current value of the working condition is equal to NCD_IDLE_EMIT (see section [^. The corrected speci¬ 
fication (which can be proved) is 

@ ensures (A_TempReadOK(T1,T2) && TempTooCold(T1,T2) && 

@ gWorkCond == NCD_IDLE_EMIT) ==> 

@ (gWorkCond == NCD_TEMP_LOW); 

This specification repeats parts of the specification of cbit_set_work_cond. It is an example of 
specification proliferation where higher level functions partially repeat and aggregate those of lower 
level functions. It leads to redundancy in the specifications which in turn leads to a higher maintenance 
effort, and it counteracts to a certain extent the well established information hiding heuristic. 

One option to alleviate the specification proliferation is keeping the call hierarchy as flat as possible 
(e.g. by avoiding input values from subroutine calls). However, this might not be possible for large and 
complex programs. Another option is to move all algorithmic complexity to the lowest levels of the 
call hierarchy and use formal specifications only at these levels. The higher level functions should have 
simple logic (at best, only call sequences) that can be easily verified by code review. 

Another alternative is to introduce predicates for the expressions shared in the specifications. A sim¬ 
ilar approach using “specification macros” has been used in the Verisoft project for recurring annotations 
[21 ■ However, this technique cannot be demonstrated with the small example used in this study. 
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6.5 WP Plugin does not support Math Functions 

The function acq_measure_temp converts the digitized voltage readings of the temperature dependent 
resistors (NTCl and NTC2 in Fig. into temperature values. In our first specification attempt we 
formulated the post-condition on the output variables tempi and temp2 with a logical function that used 
the exponential function exp as shown in the code extract below: 


//@ 

ghost 

uintl6_t D1, D2; 

/*(§ 

logic 

real R(integer T) = 

(S 


10000.0 *\exp(3988.0 

@ 



@ 

logic 

real U(integer T) = 

(§ 



(§ 

logic 

integer D(integer T) 


*/ 



*(1.0/(T+273.15)-1.0/298.15)) 
(5.0*R(T))/(R(T)+5360.0); 

= \floor(250.0*U(T)+0.5); 


/*(§ 

® , , , 

@ ensures D(*templ) >= D1 > D(*templ + 1); 

@ ensures D(*temp2) >= D2 > D(*temp2 + 1); 

@ . . . 

@*/ 

void acq_measure_temp( uintl6_t * tempi, uintl6_t* temp2); 


The logical function D{T) expresses the relation between the temperature and the digitized voltage 
reading. Is is defined by fhe femperafure characferistic of the NTCs and the electrical circuit design. The 
ghost variables D1 and D2 represent the digitized voltage readings returned by function adc_read - we 
have used here the same approach as in section 6.2 The ensures clauses use the logical function to 


constrain the values of the output variables tempi and temp2. 

We had to learn that the WP plugin in the version used for the study did not recognize standard 
math functions. It is possible to extent the WP plugin to incorporate own definitions of these functions. 
This is not a trivial task and very likely out of scope for SMEs. However, a specification of math 
functions would be very useful across many formal specification projects. Section 3.2 of the ACSL 
manual |41 announces a library for logic specifications of math functions which would be very helpful 
for requirements specifications as intended here. 

In a second attempt we defined the logical function D{T) as a piece-wise linear approximation with 
ghost arrays containing the sampling points. This was accepted by the WP plugin, but the verification 
attempt failed due to timeouts. We were not able to explain the timeouts in the time available for the 
study. 

Note that the implementation of the function acqjieasure_temp does not use math functions but 
iterates through a look-up table of 100 pre-calculated values. 


6.6 Compiler specific Language Extensions 

The source code of the real world example uses compiler specific language extensions for easier access 
to hardware registers. These language extensions are obviously not known in standard C and therefore 
not in the WP plugin. There are three possible solutions to this problem: 
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Table 1: Verification Status of Temperature Monitoring Functions 


Function 

scheduled 

Proof Obligations 
valid unknown 

timed out 

cbit_set_work_cond 

6 

5 

1 

0 

cbit_check_teniperature 

22 

17 

5 

0 

acq_measure_tenip 

237 

221 

1 

15 

adc_read 

- 

- 

- 

- 


1. Ban compiler specifics by coding standard. 

2. Define semantics of compiler specifics to make it known to WP plugin. This is very laborious and 
has not been tried. 

3. Only use compiler specifics in very small routines at the lowest layer and review these manually. 

The last option is probably the most practical solution, and should be enforced by corresponding 
design and coding rules. 

6.7 Modelling Hardware for Hardware Access Functions 

One property of avionics software is that it needs hardware related programming (section [^. Specifi¬ 
cation of hardware access functions requires modelling of hardware in ACSL. The hardware interacts 
with the external world which operates independently of the software so that the hardware modifies the 
content of program variables in a way that is not visible in program statements. 

ACSL offers so called volatile ghost variables to model side effects such as hardware interaction but 
this concept was not implemented in the Fluorine version of Frama-C that was used for the study. 

The solution to this obstacle is the same as in section 16.61 all hardware access shall be concentrated 
into small subroutines which is common programming practice anyway. These hardware access func¬ 
tions are formally specified like the other functions, but then reviewed manually for compliance with the 
LLR instead of using automated proof. 

The micro controller that was used in the project provided up to sixteen ADC channels onboard. We 
modelled the set of ADC channels as a ghost array and used this model to specify and partially verify 
that the correct ADC channels were used for temperature monitoring. 


7 Verification Summary 


Table [T] provides an overview over the verification attempt of all four functions considered in this study. 

The WP plugin could not be executed on adc_read because of the non-standard C statements in the 
source, see section |6.7[ We were able to explain all proof obligations for which a proof attempt failed 


except for the 15 proof obligations of acq_measure_temp that timed out. We were not able to conclude 
the analysis of the problem due to lack of time. It is not uncommon to use alternative provers (which is 
supported in Frama-C), but this requires additional effort to understand, install, configure and use these 
provers. 
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8 Results 

This section matches the experience made in conducting this experiment against the criteria established 
in section 12 

Familiarity with Notation and Method. We had some exposure to formal methods from past experi¬ 
ence with algebraic specifications and with the formal notation Z (HSl) as well as his participation in the 
research project Verisoft XT, but did not have working knowledge of ACSL and the Frama-C tool suite. 

The ACSL notation is quite close to the C programming language syntax, a couple of additional 
language constructs must be familiarized. However, even the simple example that had been chosen for 
this study required some more sophisticated concepts such as ghost variables, logic functions, axioms 
and labels. As a consequence, the specifications are not simple to read for the untrained. 

One particular difficulty is to find fhe correcf and mosf efficienf loop invarianf, which however is a 
common problem fo formal proof. 

If should be nofed fhaf fhe amounf of insfrumenfafion in form of assertions and loop invarianfs is in 
the same order of magnitude as the size of the source code, or even exceeds it. This is to be expected and 
in line with DO-178 objectives where all source code must be traceable to requirements. 

Complexity of the Formal Language. The language is very close to C syntax and is therefore familiar 
to C programmers. However, for more sophisticated specification tasks, the available ACSL constructs 
need a much deeper knowledge. Some specification tasks require learning of additional languages (e.g. 
YA or LTL for Aorai). 

Training. We are only aware of training sessions at conferences, and of courses and project consul¬ 
tancy that had been offered by the Fraunhofer FOKUS institute. Also the recently founded company 
TrustinSoft offers consultancy for Frama-C. 

Information Sources. A few online resources are available, mostly tutorials and papers. The most 
efficient source of information is the Frama-C mailing list, accessible via the Frama-C Website |[T2l 
where the members of the Frama-C community provide fast and accurate advice. 

Tool Maturity. We had difficulties installing the tool set on our Linux distribution (Archlinux 3.14.4-1) 
and on Cygwin over Microsoft Windows 7. With assistance of the tools mailing list and the forum of the 
Linux distribution we managed to install a command line version of Frama-C with the WP plugin and 
the Alt-Ergo proof engine on the Linux system. Although problems early on in the tool’s usage can have 
detrimental effects on an organization’s acceptance of the tool, this is considered a minor problem. 

The WP plugin should be extended to include all ACSL features and support of mathematical func¬ 
tions. 

User Guidance provided by Tool. The tool, even the command line version, highlights the goals that 
cannot be proved. It is possible to record the verification conditions that the tool generates. However, 
these are formulated in an intermediate language as input to the prover which is quite different to the C 
or even ACSL syntax. Analysis of verification conditions requires deep knowledge of automated prover 
technologies. 
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We were not able to prove all generated proof obligations and could not explain all discrepancies 
in the time that was allocated for this study. It may be possible that the Frama-C GUI together with 
interactive provers provide more debugging support - which we could not test due to the aforementioned 
installation problems. 

9 Conclusion 

During analysis several smaller deficiencies were discovered in the low-level requirements. The formal¬ 
ization of natural language requirements into ACSL is an excellent tool to “debug” specifications and 
to improve their quality. Moreover, the formalization helps to achieve many of the DO-178C objectives 
related to LLR. 

At this time of writing, we recommend to use ACSL and Frama-C only in highly safety critical ap¬ 
plications and even there only in areas that need extra scrutiny. And even so, the team must be supported 
by an experienced consultant for both tool and method who can provide immediate assistance in case 
specification or verification problems occur. We also suggest to collect and publish a set of specification 
patterns or best practices similar to those for Z ifTTlITQll . 

If formal specification is used, then additional rules must be added to the software design and coding 
standards in order to facilitate formal verification. Such rules would include the reduction of the call 
hierarchy, the reduction of internal state where possible and the increase of parameter passing as main 
method of data flow. The decision to use ACSL for specification and verification will shape the software 
design and coding practice. 

Since formal methods have made their way into aviation standards and guidelines it is to be expected 
that they will be mandated in certain areas in the future, if not by the certification authorities, then by 
major aerospace companies like Airbus and Dassault. Since the WP plugin did not fully implement 
the ACSL language standard at the time of the experiment, we also recommend to observe the further 
development and to repeat this study in one or two years. 
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